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TELEVISION COMMERCE SYSTEM WITH PROGRAM IDENTIFIERS 

Relationship To Other Applications 

This application is a continuation-in-part of pending 
Application Serial No. 09/384,182 filed on August 27, 1999, 
and includes the disclosure of provisional Application 
5 Serial No. 60/165,449 filed on November 15, 1999. 

Field of the. Invention 

This invention relates generally to an interactive 
television commerce system, and in particular, to the use 
of program identifiers to properly synchronize a viewer's 
10 receipt of product related information with the programming 
to which it is related. 

Background of the Invention 

The Internet is growing rapidly and has emerged as a 
significant interactive medium for entertainment, 

15 communications, research, education and e-commerce. 
However, Internet access generally requires a personal 
computer, and some consumers may have little need or desire 
for a personal computer, either because it can be costly, 
or because it can be difficult or complicated to use. For 

20 such consumers, it may be preferable to receive electronic 
information and entertainment services through their 
television sets. A television-based approach to e-commerce 
would appear to be an attractive alternative for many of 
these consumers. 
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Interactive television is developing rapidly and 
permits the viewer to participate in a wide range of 
activities, such as information retrieval, video games, and 
purchasing of goods and services. In a traditional cable or 
5 satellite television system, a set top box receives 
multiple channels of programming content from a cable or 
satellite television operator, and transmits to the 
television receiver the specific programming content on a 
channel selected by the viewer. The transmission of 

10 information occurs in one direction only, from the cable 
operator, via the set top box, to the television receiver 
for viewing by the viewer. In an interactive television 
system, by contrast, the set top box also functions as an 
intelligent communications terminal, and is able to store 

15 and run application programs that permit two-way 
communications between the viewer and the cable operator to 
support a wide variety of interactive functions. 

Cable television system operators, referred to here as 
multiple system operators (MSO) , are currently deploying 

20 digital broadband delivery systems (DBDS's) capable of 
supporting interactive television commerce. The terminology 
used here is essentially that of Scientific-Atlanta, Inc., 
but the components described could be used in other 
systems. DBDS allows the MSOs to offer their subscribers 

25 digital content that looks better than cable transmitted 
analog programs, and allows more digital channels to run on 
the same cable wire (at least 8 times as many) . DBDS also 
offers two-way messaging between the cable network and set 
top boxes, allowing MSOs to offer customers interactive 

30 applications such as near video on demand and email. DBDS 
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is designed as a client server network with client 
applications running on set top boxes that communicate with 
an application server that provides the content for the 
client applications. 
5 DBDS has several components that work together to 

deliver these broadband digital services to consumers. 
Analog set top boxes are replaced by digital set top boxes, 
referred to as digital home communications terminals 
(DHCTs) . A DHCT is essentially a small network computer 

10 that provides a subscriber with the ability to run multiple 
applications. It also provides Internet protocol (IP) 
connectivity back to a server via a hybrid fiber coax (HFC) 
line wired to the subscriber's home to allow an application 
running on the DHCT to interact with the DBDS. 

15 A digital network control system (DNCS) is a server, 

typically UNIX based, that controls the configuration of 
the entire DBDS, routine DBDS maintenance, SNMP monitoring, 
the broadcasting of data to the set tops, and the 
registering of additional applications that run on the 

20 DBDS. One DNCS can currently handle up to two hundred 
thousand subscribers . 

A broadcast file system (BFS) is a component of the 
DNCS and is essentially a file system containing system 
data (such as DHCT configurations) and application data. 

25 This file system is continuously broadcast in a carousel 
fashion over the DBDS via an in-band data path (IDP) and an 
out-of-band data path (ODP) . DHCTs can then access the BFS 
in much the same way that a PC accesses a hard drive. 

The IDP is a 27 Mbps data channel that the DHCTs tune 

30 to, much like any other programming channel. The path is 
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physically provided by a broadband integrated gateway (BIG) 
and an in-band quadrature amplitude modulator (QAM) . In 
essence, these pieces of hardware are employed to create a 
27 Mbps path over which the BFS is continuously broadcast 
5 to the DHCTs. Once the DHCT is tuned to the data channel, 
it can read the BFS data carousel at this high speed. This 
is useful for loading a new application on the DHCT as well 
as in any situation where fast access to the BFS is 
required. The IDP is one-way; no programming content can be 
10 received while the IDP data is being read. 

The ODP is a data channel that can be accessed while 
l programming content is being sent to the DHCT. The two 
j components that make up the ODP are a forward data channel 
if (FDC) that broadcasts out to the DHCTs and a reverse data 
-J 15 channel (RDC) that receives data from the DHCTs, both at Tl 
fli speed. The FDC interface to the HFC is provided by a 
quaternary phase shift key (QPSK) modulator. The RDC 
± interface to the HFC is provided by a QPSK demodulator. In 
% essence, this equipment functions as a modem to bridge the 
320 HEC to an Ethernet component of the DBDS. The FDC and RDC 
are used by server applications to communicate with the 
DHCTs. 

Cable head end application servers reside on the same 
IP network as the DNCS, and provide a hardware platform for 
25 running server based software applications that will be 
provisioned to the DHCTs, such as near video on demand and 
email. Services that run in the DBDS have a component 
running on the application server and are registered with 
the DNCS. 
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While it is common on television to provide 
informational messages to viewers independently of any 
programming content, such as in the case of severe whether 
warnings, it is more useful and beneficial, particularly 
5 where the informational message is intended to elicit a 
response, to be able to have such message displayed in 
conjunction with the particular program to which the 
message relates. For example, a viewer may be given the 
opportunity to register his or her assessment of the 

10 television program being viewed, to indicate his her desire 
to receive marketing or promotional materials or samples of 
a particular product or service being advertised on that 
program, or even to purchase such products and services. 
Viewing the information message in conjunction with a 

15 related program creates a sense of immediacy or urgency 
that increases the likelihood of the viewer responding to 
the message. 

In such a system, it is critical that the 
informational messages be available for display to the 

20 viewer at the appropriate point within the associated 
program. If, for example, the intention is to solicit the 
viewer' s interest in receiving a glossy brochure on a 
particular automobile during a commercial for that same 
automobile, then it is important that this message be 

25 available only during the typical 30-second duration of 
such a commercial. Receiving the message before the 
commercial might confuse or even irritate the viewer, since 
it would not be clear why the apparently unrelated message 
is being displayed. Conversely, if the message appears 

30 after the commercial has ended and the sleek, gleaming 
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vehicle is no longer visible on the screen, the viewer's 
excitement and interest in the vehicle might have already 
faded. 

Although it is possible to use pre-existing program 
5 schedule information, including time and channel, to 
establish a relationship between a viewer' s request for 
information and the programming being viewed at the time of 
the request, such an approach is subject to schedule errors 
and unforeseen schedule changes. Often, precise schedules 

10 of commercial messages are simply not available to third- 
party television commerce service providers. 

What is needed is a system for providing interactive 
e-commerce on a television distribution network, that can 
reliably synchronize the delivery of product related 

15 information to the programming to which the information is 
related. The system should provide notification to the 
viewer in a timely manner of the availability of such 
information, respond promptly to user requests for the 
information, and avoid reliance on program schedule 

20 information, such as time or channel, in order to correctly 
retrieve the desired product information for the user. 

Obj ectives 

Therefore, it is an objective of the present invention 
to provide a system for making available product related 
25 information that is synchronized with a related television 
program. 

It is another objective of the present invention to 
ensure that viewers are timely notified while viewing 
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television programming of the availability of related 
product information . 

It is a further objective of the present invention to 
facilitate prompt and correct responses to viewer requests 
5 for product related information.lt is yet a further 
objective of the present invention to synchronize the 
provision of product related information to its associated 
programming in a manner that accomodates errors and 
unexpected changes in program schedule. 
10 The above objectives, as well as other objectives, 

features and advantages of the present invention will 
become readily apparent from the following detailed 
description, which is to be read in conjunction with the 
appended drawings . 

15 Summary of the Invention 

The present invention includes a commerce control 
network (CCN) system and methods for obtaining product 
information and for purchasing products through a two-way 
interactive television system. 

20 In one aspect, the invention includes a three. -tier 

architecture that has client applications residing in 
individual set top boxes; a commerce transfer point (CTP) , 
including at least one commerce application server (CAS) 
and at least one head end database server (HEDS) ; and a 

25 remote commerce control point (CCP) coupled to one or more 
CTPs. The commerce application server communicates between 
the client applications and the HEDS, which stores commerce 
control network data such as product, user and broadcast 
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information. The HEDS communicates with the CCP to transfer 
commerce control network data back and forth. The CCP would 
typically be coupled to a number of HEDS, and the data in 
each HEDS would be periodically replicated in the CCP. 
5 According to another aspect of the invention, user 

requests for information are categorized either as high 
priority requests or as low priority requests, and placed 
in separate queues at each HEDS, which is the network 
server that preferably handles such requests. Use of 

10 multiple queues helps make possible the processing a large 
number of use requests that may occur at the same time in 
response to a particular program segment. The high 
priority queue is preferably a real-time queue, while the 
low priority queue may be a batch queue. 

15 In another aspect, the system of the present invention 

can provide product information or a purchase screen for a 
list of products in a manner related to underlying 
broadcast programming content. The product information can 
be provided to the user in response to a user input. For 

20 example, a user can press a certain key on a television 
remote control upon seeing an icon during programming and 
access a simple electronic buying guide that displays to 
the user a list of products that are related to that 
programming. The information that is displayed may be on a 

25 translucent screen, on a screen that blocks part of the 
programming, or on a full screen. 

By using the remote control, the user can also enter a 
more comprehensive electronic buying guide. This electronic 
buying guide preferably has a scrollable list of items, a 

30 detail window that provides detailed information about the 
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attributes of an item in the list * that the user has 
selected, and a video window that captures the programming, 
all displayed at the same time. 

In another aspect, the system of the present invention 
5 allows the user to select an item from a displayed list of 
products and store it in a server (such as in the HEDS) in 
a list that is personalized for the particular user and 
accessible so the personalized list can be retrieved at a 
later time by the user. This accessible and personalized 

10 list in essence functions as a persistent shopping cart 
containing the user's favorite items. 

In accordance with another aspect of the invention, 
the icon displayed with the video programming, to indicate 
that commerce related information is available on the tuned 

15 channel, can be triggered by data received with the 
broadcast programming, so as to be simultaneously displayed 
with a predetermined portion of the programming. When the 
user makes an input in response to the icon, further 
commerce related information is accessed by the system and 

20 broadcast to the user. 

In a further aspect of the invention, video 
programming is broadcast with a plurality of program 
identifiers, each program identifier being uniquely 
associated with a particular segment of the video 

25 programming. The set top box at each user station, 
receives each video programming segment with its unique 
identifier and can, preferably in response to a user input, 
transmit a request, containing the unique identifier, to 
the broadcast station from which the video programming was 
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broadcast. Typically, the broadcast station is at the head 
end of a cable television distribution system. 

The broadcast station uses the unique identifier 
included in the product related request to retrieve product 
5 related data from a database associated with a system 
server, also typically located at the head end in a cable 
television system. By using the unique program identifier 
included in the user's request, the system can correctly 
retrieve the product related data intended for the program 

10 segment being displayed to the user, without the need to 
use program schedule information, such as time and tuned 
channel, and therefore, unaffected by program schedule 
errors or changes. 

The unique program identifier can also be used by the 

15 set-top box, when received at the user station, to trigger 
the display of an icon to notify the user of availability 
of product related data associated with the programming 
segment then being viewed. Based on the first product 
related data received, preferably a listing of available 

20 products, the user can interact with the system to obtain 
detailed information about the attributes of selected 
products, or to purchase products, associated with the 
programming content, in the manner discussed above. 

The system of the present invention may be used in a 

25 widely available television network, such as a cable 
television system or a satellite television system 
available over a wide area and to a very large number of 
users. The system of the present invention is simple to 
operate, in that it is completely functional from a 

30 television remote control, and it provides enhancements to 
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the traditional broadcast entertainment programming 
currently available through cable and satellite operators. 

Brief Description of the Drawings 
Fig. 1 is a block diagram of a commerce control 
5 network according to the present invention. 

Fig. 2 is a software process diagram of the commerce 
applications server . 

Fig. 3 is a software process diagram of a head end 
database server. 

10 Fig. 4 is a block diagram of a commerce control point. 

Figs. 5(a) — 5(d) are block diagrams of screen shots 
and portions of screen shots for the guick buy client 
application . 

Figs. 6(a) — 6(f) are block diagrams of screen shots 
15 and portions of screen shots for the electronic buying 
guide application . 

Fig. 7 is a block diagram of a system illustrating the 
use of a program identifier. 

Fig. 8 is a functional block diagram of a set top box 
20 and other items comprising a typical user station. 

Detailed Description 

Referring to Fig. 1, the present invention includes an 
interactive television commerce system, referred to as a 
commerce control network (CCN) 10, in an interactive 
25 television system, such a cable television system described 
above or a satellite television system, that is widely 
available to a large number of users, e.g., over a 
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metropolitan area. CCN 10 allows TV users to select, 
purchase, gain additional information about, and store 
information relating to products using a simple and 
convenient menu-based user interface. The system can 
5 provide product lists that may or may not be customized 
based on a particular channel and/or program being watched, 
or the product lists or other information can be tailored 
for the individual user. 

In one instance of the system, if a user orders a 
10 product, the order can be processed by the system, the 
user's credit card may be billed, inventory may be updated, 
3 and the order may then be forwarded to a warehouse for 
shipment. In another instance, if a user orders a product, 
3 the order can be processed by the system and then forwarded 
jl5 to an appropriate third-party vendor for billing and 
i fulfillment. In the latter instance, periodic status 
updates on the order may be provided by the vender to the 
^ system. The system, referred to here as an electronic 
=j buying guide (EBG) , is not strictly limited to "buying," 
320 but can also include obtaining product information and 
. samples. 

CCN 10 of the present invention has a three-tiered 
architecture with client applications 12; a commerce 
transfer point (CTP) 22, and a commerce control point (CCP) 
25 24. 

Fig. 8 shows a functional block diagram of a set top 
box 18, and other items comprising a typical user station 
in the commerce control network 10 of Fig. 1. Client 
application 12 runs on processor 84 under a set top 
30 operating system (OS) 89, such as the PowerTV Set Top OS, 
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which is currently being provided with a Scientific-Atlanta 
DHCT, or under a Windows CE OS. In the case of the PowerTV 
OS, client application 12 may be created using a PowerTV 
development kit. The PowerTV OS provides a full-featured 
5 application programming interface (API) that allows a 
developer to isolate the application code from the hardware 
level of the set top box. 

Client application 12 provides the user with a 
convenient user interface that is controllable by the user 

10 with an input device 86, preferably a standard STB remote 
control, to allow viewing, purchasing, or obtaining 
information about products. The input device may be 
connected to STB 18 directly or, more typically, by 
infrared link 85. The viewer can thus conveniently access 

15 the application via a remote control button while watching 
television. 

As will be explained in further detail below, client 
application 12 directs the display of product related 
information on a display screen 88, usually a standard 

20 television set, and can do so simultaneously with display 
- of the programming to which STB 18 is tuned. A tuner 82 
can be tuned to a multiplicity of broadcast channels on a 
broadcast distribution network (DBDS) 26 to receive in-band 
video, audio and data 81, for display to the user. 

25 The functionality to call the client application is 

built into a resident application 87 that runs on STB 18 
and can be provided by a variety of third party vendors. A 
client application executable is loaded onto STB 18 from 
broadcast distribution network (DBDS) 26 when resident 
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application 87 determines that the user has tuned to a 
channel that is configured to run the client application. 

In addition to in-band path 81, tuner 82 also provides 
5 a bi-directional out-of-band data path 83 over which 
processor 84 sends product related requests, generated in 
response to user inputs, to CTP 22, and over which 
processor 84 can receive product related data from CTP 22. 

The term "set top box" is meant broadly to include a 
10 processing functionality with a television set; that 
functionality could be integrated into the television set 
itself, for example, and thus need not be literally in a 
separate standalone "box." 

Again with reference to Fig. 1, CTP 22 includes one or 
15 more commerce application servers (CAS) 16, each in 
communication with a number of set top boxes; one or more 
head end database servers (HEDS) 14, each connected to one 
or more CASs; a private Ethernet network for connecting 
CASs and HEDSs; and a private wide-area network connection 
20 21 for communication with CCP 24. CTP 22 handles all of the 
- requests from the client applications 12, and serves as a 
data conduit to CCP 24. In the case of a cable television 
system, the CTP is preferably located at the cable head 
end. 

25 CAS 16 is responsible for registering CTP 22 for use 

within the DCN of the local MSO, and for providing client 
application 12 to DBDS 26 for distribution to set top boxes 
18. The CAS also serves as the point of communication 
between client applications 12 and HEDS 14, and thus CAS 16 

30 handles all client application 12 requests and forwards 
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them to HEDS 14. The number of CAS 16 machines may be set 
as needed based on the number of STBs 18. 

CAS 16 is preferably implemented by a small server, 
such as a Compaq Proliant Model 1600R running Windows NT, 
5 preferably with message queuing software such as Microsoft 
Message Queue (MSMQ) . CAS 16 utilizes at least one Ethernet 
card to access HEDS 14 and at least one asynchronous 
transfer mode (ATM) card to access DBDS 26 via an ATM 
switch, such as a Xylan ATM switch. The system can have one 

10 more CAS 16 than is needed to handle usage so that in the 
event of a failure of one CAS, the overall system will 
still handle the full processing load. 

Referring to Figure 2, CAS 16 has three components 
implemented in software, socket server process 200, which 

15 manages the client TCP/IP connections; message queuing 
component 202, which provides the message queuing 
functionality; and database process 204, which processes 
client requests and provides database access. 

Socket server process 200 has at least two functions: 

20 a receive service, ServerRX- 206, and a transmit service, 
- ServerTX 208. ServerRX 206 manages client connections from 
a number of client applications 12, reads the client 
requests, and puts each such request message in an 
appropriate inbound queue in message queuing component 202 

25 based on header information contained in the request. 
ServerTX 208 scans the outbound queue of message queuing 
component 202 for replies from the database, opens 
connections to the appropriate client applications 12, and 
forwards the replies to the clients. 
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Message queuing component 202 is preferably 
implemented as multiple queues. For ServerRX 206 
communications, there are at least two queues: inbound real 
time queue (IRTQ) 210 and inbound batch queue (IBQ) 212. 
5 The request messages from the client applications have 
header information that indicates the response priority. A 
client application request whose header information 
indicates that the request requires an immediate answer 
will be placed in the real time queue 210. A client 

10 application request whose header information indicates that 
the request does not require an immediate answer will be 
placed in the batch queue 212. 

Database process 204 has a number of single database 
programs 216, each of which can service incoming client 

15 application requests from message queuing component 202. 
Each database program 216 processes one inbound request 
from message queuing component 202 at a time. Each database 
program 216 first processes requests in IRTQ 210. If IRTQ 
210 is empty, each database program 216 processes requests 

20 in IBQ 212. Database program 216 can then submit a request 
_ to the associated HEDS 14 and wait for a reply. When a 
reply is received, database program 216 forwards that reply 
to outbound message queue (OMQ) 214. Messages are retrieved 
from OMQ 214 by ServerTX 208, which functions as described 

25 above . 

The use of these multiple queues and database programs 
helps make possible the processing of a large number of 
requests by users through their client applications at the 
same time. 
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Referring again to Figure 1, each CTP 22 contains at 
least one HEDS 14 to provide all persistent data storage, 
including customer information, order status, program data, 
item information, and item descriptions. HEDS 14 is 
5 preferably implemented by a small server, such as a Sun 
Sparc 1 running Solaris or an IBM R56000 Model C20 running 
AIX, and preferably with a relational database management 
system (RDBMS) 15, such as an Oracle RDBMS. The use of an 
RDBMS is desirable because an RDBMS allows for scalable 

10 access to large amounts of data. HEDS 14 preferably has at 
least one Ethernet card to communicate with one or more 
CASs 16 via a private Ethernet network 17 and at least one 
Ethernet card to communicate with CCP 24 via wide-area 
network 21. HEDS 14 also has a console for either local or 

15 remote maintenance and operation. 

Referring to Figure 3, database program 216 submits 
requests to HEDS 14 via remote access software 302, such as 
Oracle SQL*NET . The requests include information for 
directing HEDS 14 to execute any one of a number of stored 

20 procedures 304 on RDBMS data. Stored procedures 304 contain 
- the business logic for supporting certain applications in 
the network, such as an electronic buying guide application 
and a quick buy application (discussed below) . 

RDBMS data is populated by multiple sources. These 

25 sources include CCP 24, which can provide data such as 
broadcast schedules, product lists, product information and 
order status information; CAS 16, which provides data from 
user inputs such as credit card data, pass codes, multiple 
user profiles and specific transaction information; and an 

30 MSO billing system, which provides household specific 
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information including name, address, telephone number, and 
an unique identifier for a user's STB. 

HEDS 14 combines specific transaction information with 
credit card, information and household specific information 
5 and forwards the combined information to CCP 24 in a real 
time or in near real-time fashion periodically at some 
desired time, which may be different for different types of 
information (e.g., general requests for information may be 
transferred at a slower rate than orders from customers to 

10 purchase products) . The CCP thus replicates what is in the 
different HEDSs in communication with it. HEDS 14 also 
monitors portions of the system to ensure proper operation 
and generates alarms to CCP 24 when problems are detected. 

Referring to Fig. 4, commerce control point (CCP) 24 

15 preferably includes at least one of each of the following 
components: a CCP server 20, a scheduling system 30, a 
general ledger system 32, a data warehouse 34, an internal 
reporting system 36 and an external reporting system 38. 
CCP server 20 can be a large, highly available UNIX based 

20 server with a separate disk farm and an RDBMS. Scheduling 
- system 30 can be a UNIX based server with an RDBMS. General 
ledger system 32 can be a component of a standard 
accounting system software package. Data warehouse 34 can 
be a large UNIX based server with a separate disk farm and 

25 an RDBMS. Each reporting system can be a Windows NT 
workstation. CCP 24 may reside at a dedicated location or 
locations such as a collocation area of a telephone company 
central office or point of presence. CCP 24 also performs 
various maintenance and monitoring functions on its own 

30 systems to alert operators when any problems are detected. 
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CCP server 20 communicates bi-directionally with one 
or more commerce transfer points (CTPs) 22 and provides 
data, including broadcast schedules, product lists, product 
information and order status information, to each such CTPs 
5 22. CCP server 20 also aggregates user data in order to 
create user profiles. These user profiles can be compared 
to a stored product list and then used to allow a product 
lists to be customized for groups of users or for each 
individual user, or to associate one of a number of product 

10 lists to each user. 

CCP server 20 interfaces with vendor e-commerce 
systems 28 to forward sales orders, obtain inventory 
control information, authorize and settle credit card 
transactions, and provide order fulfillment. CCP server 20 

15 can have a number of external data feeds 42. In the 
preferred embodiment, these feeds include an interactive 
program guide (IPG) data 40, which provides raw broadcast 
schedules, and MSO customer data 44, which provides the 
customer name, address and phone number associated with a 

20 unique set top box identifier. 

Scheduling system 30 receives IPG data 40 and raw 
vendor product lists from CCP server 20, and provides to 
vendors a web-based interface for each vendor to designate 
which products from such vendor' s raw product list are to 

25 be associated with which programming. The scheduling system 
then forwards the configured information back to CCP server 
20, which in turn forwards the configured information to 
the appropriate CTPs 22. 

General ledger system 32 can record all of the 

30 commerce control network's billable transactions downloaded 
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from the CCP servers 20, and then can aggregate transaction 
information on a vendor-by-vendor basis for invoicing and 
financial reporting. Ledger system 32 can perform a similar 
function for other network participants such as MSOs. 
5 Data warehouse 34 stores a near real time image of all 

of the data resident in each of the CCP servers 20. This 
data is used by internal reporting system 36 and external 
reporting system 38 to generate detailed reports without 
using the processing resources of the CCP server. Internal 
10 reporting system 36 generates reports relevant to the 
operation of the CCN, such as exception reports and CCN 

2 marketing reports. External reporting system 38 generates 
"J reports configured in any reasonable manner deemed useful 

3 by vendors or other CCN participants, such as vendor sales 
jl5 and demographics reports. 

f Referring to Figs. 5 (a) -5(d) in general, one 

embodiment of client application 12 is a quick buy 
^ application (QB) 400. Referring particularly to Fig. 5(a), 
=f when the user tunes STB 18 to a certain channel which has 
320 been pre-conf igured to function with the QB 400, STB 18 
- resident application responds by loading the QB 400 
executable file from the MSO' s head end network file system 
(such as the Scientific Atlanta broadcast file system) . 
Once loaded and running in the memory of a STB 18, QB 400 
25 displays the video and audio portions of the tuned channel 
and can display a quick buy icon 402 indicating that the 
tuned channel is QB 400 enabled. In the preferred 
embodiment, the icon is static; however, it could also be a 
dynamic mix of graphics and text, and it can be flashed at 
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certain times to encourage the user to enter a purchasing 
mode . 

The presence of quick buy icon 402 informs the user 
that QB 400 is running and therefore that the user may 
5 enter a purchasing and product information mode by pressing 
a defined key on the user's remote control. In an 
alternative embodiment, the user may enter a purchasing 
mode by pressing a defined key on the STB remote control 
even when the icon is not present to enter QB. 
10 Once the user enters the purchasing mode, QB 400 sends 

a client request to commerce transfer point (CTP) 22, which 
=i processes the request as described above and sends a 
J database reply containing the list of product information 

*■=! 

3 associated with the tuned channel and current time, i.e., 
115 the programming. Alternatively, CTP 22 can send a database 
3 reply with a list of products or product information that 
may be tailored to that user, or may be general product 
7 information provided to all users. 

3 Referring to Fig. 5(b), QB 400 displays a tab screen 

J 

120 600 containing a product list and certain product 
" - information, such as prices for each of the items. A 
possible embodiment of the tab screen 600 displayed by QB 
400 could be configured as shown in quick buy tab 406. 
Quick buy tab 406 may be translucent and overlays a portion 
25 of the video of the tuned channel. When quick buy tab 406 
is displayed, QB 400 can remove the quick buy icon, if any, 
from the television screen. 

The user can use standard tab screen navigation 
techniques (described below) to select a line item 614 from 
30 a list box 612 by pressing a defined key on the user's STB 
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18 remote control. The user may select a line item 614 for 
one of a number of purposes indicated by buttons 624 and 
button text 626. By selecting one button, the item can be 
saved into a customized and personalized list (referred to 
5 here as a "Favorites" list) that is stored in the CTP, such 
that the personalized list can be accessed at another time. 
By selecting another button, the user can enter the 
electronic buying guide discussed below. By selecting yet 
another button, the user can indicate a desire to purchase 
10 at the current time and then enter a credit card number. 

Referring to Fig. 5(c), in response to the user 
j selecting a product to purchase and entering appropriate 
* information (which may be configured in the client 
3 application to prevent entry for every purchase) , QB 400 
jl5 confirms the order by displaying a confirmation tab 408. 
:? The user can confirm the order or go back to the prior 
screen. If the user rejects the order by pressing a key on 
a the user's STB 18 remote control defined by a button on the 
^ order confirmation tab 408, QB 400 redisplays quick buy tab 
320 406. If the user confirms the order, QB 400 forwards the 
- order to CTP 22 for processing. As discussed above, CTP 22 
will forward the information to the CCP, which may handle 
the request, or which may forward the request to a separate 
vendor e-commerce system for processing. 
25 Referring to Fig. 5(d), the system then displays a 

thank you tab 410, removes all tab screens from the video 
display, and can redisplay quick buy icon 402 if configured 
to do so or simply remove all non-programming information 
from the screen. 
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If the product selected requires additional 
configuration, such as quantity, style, size, etc., prior 
to purchase, QB 400 launches another client application 
referred to here as the electronic buying guide (EBG) 500 
5 and passes the existing purchase parameters to the EBG. EBG 
500 can also be launched from QB 400 via a button shown in 
Fig. 5(b) on quick buy tab 406, or can be launched in other 
ways including via an STB 18 remote control key defined and 
processed by the STB 18 resident application, and via the 
10 user tuning the STB 18 to a channel dedicated to the EBG 
500. 

When EBG 500 is launched, by whatever means, the STB 
18 resident application responds by loading the EBG 500 
executable file from the MSO' s head end network file system 

15 (such as the Scientific Atlanta broadcast file system) . 
Once loaded and running in the memory of the STB 18, EBG 
500 displays a graphic screen configured, for example, as 
illustrated in Figure 6(a). EBG 500 graphic screen may 
include at least one detail window 502, at least one video 

20 capture window 504, and at least one tab screen display 
- window 506. 

Referring to Fig. 6(b), detail window 502 provides 
additional detail about products that may be purchased, or 
for which more information can be displayed. Detail window 

25 502 may include any of the following: a header 508, at 
least one graphics box 510, at least one text box 512 and 
at least one input box 514. Header 508 can contain text 
much like the text box described below. The graphics box 
510 can display a picture in any one of a number of formats 

30 such as bitmap (.bmp), joint photographic experts group 
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(JPEG), graphics interchange format (.gif), etc. Text box 
512 can be configured to display text in various font 
styles and point sizes and may or may not include a 
scrolling feature for text of a length exceeding the size 
5 of the box. Input box 514 is a data entry field which can 
be populated by the user in several ways. For example, it 
can be populated by the user directly from STB 18 remote 
control numeric keys, or by a pull-down menu containing a 
predetermined number and type of data options from which 

10 the user can choose. 

The detail window can be configured as desired to 
provide information about the product. Accordingly, the 
detail window may have text only, a photograph, a moving 
image, or a desired combination of text and graphics. 

15 Referring again to Fig. 6(a), video capture window 504 

displays video in any of a number of formats, such as MPEG 
or MPEG 2. The video being displayed can be captured from 
various sources, but it will most typically be captured 
from the tuned channel at the time the EBG was invoked. 

20 Referring to Figs. 6(c) and 6(d), tab screen display 

- window 506 has at least one tab screen 600. When more than 
one tab is presented in tab screen display window 506, tab 
602, screen detail 604, and button bar 606 of an active tab 
screen 516 are displayed, but only tab 602 of each inactive 

25 tab screen 518 is displayed. The user can switch from the 
active tab screen 516 to an adjacent inactive tab screen 
518 by pressing a defined STB 18 remote control key such as 
the left and right arrow keys. In another embodiment, the 
user can switch from an active tab screen 516 to an 

30 inactive tab screen 518 by pressing the numeric key on STB 
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18 remote control that corresponds to a number assigned to 
a tab screen 600 , which may be displayed on tab 602. When 
such user input occurs, the active tab screen 516 becomes 
an inactive tab screen 518, and the newly selected inactive 
5 tab screen 518 becomes the active tab screen 516. 

Referring to Fig. 6(d), each tab screen 600 may 
include a tab 602, at least one section of screen detail 
604, and at least one button bar 606. Tab 602, which 
generally functions to identify the tab screen 600, can 
10 display graphics or text in various font styles and point 
sizes . 

n Referring to Fig. 6(e), screen detail 604 within a tab 

I* screen can have several components. For example, a list 608 
□ can include at least one header 610, at least one list box 
vjl5 612, at least one scroll bar 616, and a scroll bar 
!;? indicator 618. As an alternative, a text component 620 can 
£ include at least one header 610, at least one text box 622, 

: . 
r ^ 

u at least one input box 514 (see Fig. 6(b)), at least one 
^ scroll bar 616, and a scroll bar indicator 618. Header 610 
£320 can contain text much like text box 622 described below. 

List box 612 contains at least one line item 614 and 
may be configured to display a fixed number of line items 
614 at one time notwithstanding the number of items in the 
actual list to be displayed by list box 612. For example, 
25 if list box 612 is configured to display four line items 
614, but the list to be displayed by list box 612 contains 
10 items, the user can scroll upward or downward to cause 
list box 612 to display the items that are not currently 
displayed in list box 612. As the user scrolls through list 
30 box 612, the current line item may be highlighted and the 
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scroll indicator 618 in scroll bar 616 is repositioned 
relative to the current line item content position in the 
actual list, where scroll bar 616 represents the length of 
actual list. Text box 622 can be configured to display text 
5 in various font styles and point sizes and may or may not 
include a scrolling feature as described above utilizing 
scroll bar 616 for text of a length exceeding the size of 
the box. 

Referring to Figs. 6(b) and 6(f), button bar 606 may 

10 include one or more buttons 624 and button text 626. Button 
text 626 can be configured to display text in various font 
styles and point sizes and is generally used to identify 
the function of an associated button 624; however, button 
text 626 can also be utilized in the absence of an 

15 associated button 624 to convey information to the user. A 
button 624 is a virtual representation of a defined input 
key on a STB 18 remote control. A button 624 may be 
displayed on the button bar 606 graphically or textually, 
or by a combination of the two. The client application 12, 

20 such as the QB 400 or the EBG 500, maps the button 624 to 
- the corresponding STB remote control key by registering its 
interest in such a key with the STB operating system. For 
example, when the user selects the mapped key on the STB 
remote control, the STB operating system delivers the user 

25 input to client application 12, and client application 12 
in turn calls the function associated with such input. 

As explained above, EBG 500 interface can be 
configured using any combination of detail windows 502, 
video capture windows 504 and tab screen display windows 
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506, which can each in turn be configured using any 
combination of their respective components. 

In a typical embodiment of EBG 500, the functionality 
available to the user at any given time is driven by the 
5 active tab screen 516. EBG functionality presented by a 
given active tab screen 516 determines the configuration of 
the EBG interface, including the location, number and 
configuration of detail windows 502 and video capture 
windows 504 . Each of the components of the EBG 500 

10 interface provides information to the user, receives 
information from the user, or both. A number of active tab 
screens can be included in EBG 500. 

One of the screens within the EBG is a quick buy tab 
screen 600-. The functionality of such a tab is similar to 

15 that of quick buy tab 406 described above in an embodiment 
of the QB application. In both instances, the key function 
of the quick buy tab screen is to display a list of 
products, preferably associated with the underlying 
programming being displayed on the tuned channel. When the 

20 quick buy tab screen is utilized in the EBG context, the 
- tuned channel is captured in a video capture window 504 and 
a detail window 502, configured in accordance with the need 
for information about the product, is available to display 
real-time detailed product information about a given 

25 product as the user scrolls through the product list. When 
the user selects a product to purchase, the detail window 
502 can then be utilized to display further information and 
request user input, such as quantity, style, color, size, 
etc., regarding the selected product. In another instance, 
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a video capture window can be utilized to display video 
information regarding the selected product. 

Another screen is a favorites tab screen. The 
favorites tab screen can have detail similar to that shown 
5 in Fig. 6(e) and can function identically to the quick buy 
tab screen described above, except that the user, rather 
than the underlying programming, determines the content of 
the product list. The user may add items to the favorites 
list by tagging any item the user so designates as a 

10 "favorite" while viewing any other product list provided by 
any client application at any time. The favorites tab 
screen also provides the user with the functionality to 
remove items from the favorites list. The favorites list is 
stored in the HEDS 14 for later retrieval as discussed in 

15 conjunction with Fig. 2, even after the client application 
has been closed and reopened. In other words, the storage 
is essentially permanent. The user can therefore delay 
purchase of a particular item, while the favorites list 
provides a convenient way to maintain the list for the 

20 user. 

An order status tab screen displays a list of products 
recently ordered by the user and the status of each 
individual order. Each order listed can include a level of 
detail such as order date, product description and order 

25 status. In the preferred embodiment, an order's status can 
be Shipped, In Process, Pending, Back Ordered and Canceled. 
An order is "Shipped" when the vendor informs the commerce 
control network (CCN) that the product has in fact been 
shipped. An order is "In Process" when it is at a stage of 

30 processing at which the user cannot cancel the order. An 
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order is "Pending" when it is at a stage of processing at 
which the user can cancel the order. An order is "Back 
Ordered" when the vendor informs the CCN that the vendor's 
inventory of such item is temporarily depleted. Back 
5 ordered orders are cancelable by the user. An order is 
"Canceled" when the vendor informs the CCN that the user's 
credit authorization has failed, the user cancels the 
order, or the vendor has sold out of a limited quantity 
item. The order status tab screen can display each status 

10 in an appropriate color such as green for "Shipped", red 
for "Canceled" and yellow for all other statuses. Orders 
with a status of "Shipped" are removed from the user's 
order status list after a fixed period of time lapses. The 
user can obtain more information about an individual order 

15 on the order status tab screen by selecting the order for 
review, at which time the EBG will display additional 
details about the order, such as order number, shipping 
method, tracking number, shipping address, etc. 

A settings tab screen allows the user to configure 

20 certain features of the EBG. Such settings can include 
" payment information, shipping method, interface color 
scheme, security features, etc. In addition, the settings 
tab screen provides a method for configuring more than one 
user per household. Each such user can have its own 

25 security code and user profile as described below. 

A profiles tab screen allows the user, or users, to 
store default personal data, payment data and purchase 
preference data. Default personal data can include 
information such as clothing sizes, which the EBG can use 

30 to populate clothing size fields that would otherwise have 




29 



Docket No. : 3011-03 

to be populated by the user. Payment data can be user- 
specific credit card or other data that will override the 
default payment data set up for the household in the 
settings tab screen. Purchase preference data can include 
5 user-designated product cost maximums and minimums, 
preferred vendors and preferred product types. Preferred 
product types can range from broad categories such as 
books, music and clothing to narrow categories such as 
fiction, folk, and formal. The EBG can use an individual 

10 user's purchase preference data to customize product lists. 

A help tab screen can offer context sensitive or 
general help. In another embodiment of the help function, 
context sensitive help can be provided via the detail or 
capture windows while the user is navigating through one or 

15 several of the other windows displayed in the EBG 
interface . 

Referring to Fig 7, a television set 700 with set top 
box 702 receives programming and data from a cable 
infrastructure 704. Infrastructure 704 received broadcast 
20 content 706 from a satellite 708, and is coupled to a 
- network database 710 in a manner described above. The 
system can provide direct automated access to information 
in network database 710 using a unique program identifier 
embedded in a video or audio program, commercial message, 
25 or news story. 

Cable infrastructure 704 provides video and audio, 
along with data identifying the programming or commercial 
for the currently tuned channel as indicated by arrow 714. 
Programs are received through broadcast, cable or pre- 
30 recorded media, and can be * encoded in either analog or 
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digital formats. The unique program identifier can be 
encoded in a vertical blanking interval (VBI) or other non- 
displayed portion of an electronic signal which represents 
the video or audio program so as not to interfere with the 
5 program as displayed or transduced on a television or audio 
sound system. The unique identifier is detected and decoded 
from the electronic signal at the set top box 702. 

The user can make a request for information, and the 
request will include the program identifier received in the 

10 broadcast signal, as indicated by arrow 716. The cable 
infrastructure then uses that program identifier to 
retrieve and broadcast screen definition and product lists 
associated with the program identifier. Upon detecting the 
unique program identifier, the system indicates to the user 

15 that more information is available via some screen 
notification mechanism. The user may then elect to retrieve 
the information from the network database by giving a 
simple command, e.g., pushing a special button on a remote 
control. The system then automatically sends a message to 

20 the network database and retrieves the data requested for 
- display on the television. The display itself may be 
different based on the screen definition information 
associated with the particular program identifier in the 
network database. Based on the information received, the 

25 user can then interact with the system to purchase the 
products associated with the underlying content in the 
manner described above. 

While a number of embodiments have been described, it 
should be apparent that modifications can be made without 

30 departing from the scope of the appended claims. For 
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example, although the broadcast distribution network has 
been described mainly in terms of a digital broadcast 
distribution system, suitable for digital, high definition 
television broadcasting, the claimed invention is equally 
5 applicable to the analog television distribution networks 
that are still currently in place. Similarly, the present 
invention is as applicable to systems employing advanced 
analog set top boxes that support communications through an 
upstream data path, as it is to those containing digital 
10 set top boxes. 
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